「AWSクラウド活用の強力な味方 - AWSサポートの使い方」という内容で登壇しました #cm_odyssey

「AWSクラウド活用の強力な味方 - AWSサポートの使い方」という内容で登壇しました #cm_odyssey

Clock Icon2024.07.31

AWSのサービス運用で発生する様々な課題を技術支援してくれるAWSサポートは、数あるAWSサービスの中でも最も人気のあるサービスの一つです。

2024年7月16日にオンラインで開催された「7/16(火) Classmethod Odyssey ONLINE クラウド編」にて、「AWSクラウド活用の強力な味方、AWSサポートの使い方」 というタイトルで登壇しましたので、資料を共有します。

過去には、日本深夜帯のエスカレーション対応を行っており、社内ではAWSサポート、特に高緊急度な対応を数多く経験してきた方ですので、当時の体験も踏まえ、AWSサポートを最大限に活用し、課題を効率的かつ迅速に解決するためのヒントについて発表しました。

以下に登壇内容を簡単に共有します。

登壇資料

登壇動画

https://www.youtube.com/watch?v=bkWvGnJBRzk

AWSサポート使っていますか?

AWSクラウドを使っていると、S3の利用費の計算が複雑で難しいとか、EC2インスタンスにうまくアクセスできないなど、日々課題が発生します。また、クラウドは日々進化しているので、知識のキャッチアップも必要です。

こういった企業のイノベーションの課題をお手伝いするのが、今回ご紹介するAWSサポートです。

DevIO_2024_On_Effective_AWS_Support_background

東京リージョン開設時から日本語サポートを提供

日本語サポートは実は2011年から東京リージョン開設時に提供され始め、AWSが昔からサポートを重要視していたことが伺えます。

こういった背景もあり、AWSサポートと日本のAWSユーザーとの付き合いは非常に長く、 好きなAWSサービスにAWSサポートを挙げる人が多い のも納得できます。

DevIO_2024_On_Effective_AWS_Support_tokyo_region

AWS公式の技術的なお問い合わせのガイドラインをご存知ですか?

このAWSサポートには、技術的な問い合わせに対する詳細な公式のガイドラインが存在します。

なぜ公式ガイドラインが存在するのかというと、日々多くのサポートケースを効率的に早期解決するためには、優先度をつけたり、内容によって適切な担当者を割り当てたり、問い合わせ内容を正確に素早く把握することが求められるためです。

https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/

DevIO_2024_On_Effective_AWS_Support_guideline

Effective AWS Support - 10選

本セッションではこのガイドラインをベースに、AWSサポートを効率的に使うためのプラクティスを10個ご紹介します。

DevIO_2024_On_Effective_AWS_Support_10_tips

1.起票前にもう一度調べてみよう

DevIO_2024_On_Effective_AWS_Support_01

一つ目のプラクティスは「ケース起票前にもう一度調べよう」です。

同僚に相談すれば一瞬で解決するかもしれません。AWSには膨大な公式ドキュメントが存在します。また、最近ではre:PostというコミュニティベースのQ&Aフォーラムもあります。AWSの基盤に起因するような一時的な障害であれば、X(旧Twitter)のようなソーシャルメディアで報告が上がっているかもしれません。DevelopersIOのような技術ブログに回答がズバリ書いてあるかもしれません。

解決につながるようなリソースは豊富にあるので、起票前にもう一度調べてみようというのが 1つ目のプラクティスです。

2. 2種類の窓口を使い分ける

DevIO_2024_On_Effective_AWS_Support_02

2つ目のプラクティスは「2種類の窓口を使い分ける」です。

AWSサポートは アカウント系技術系 で窓口が明確に分かれています。

アカウント系 は請求や料金などAWSアカウントの運用に対してサポートします。一方で、 技術系は 、EC2やS3などAWSの技術全般に対してサポートします。例えば、S3の利用費に関する問い合わせは 「アカウントと請求」 の窓口で行い、S3のバケットポリシーなど「技術」に関する問い合わせは 「技術」 の窓口で行います。

この2つは組織が完全に分かれているからなのか、サポート担当者の文体も全く異なるのが面白いところです。

3.解決の定義を明確に

DevIO_2024_On_Effective_AWS_Support_03

3つ目のプラクティスは「解決の定義を明確に」です

ケースを起票するということは、自分ではない第3者にシゴトを依頼することです。
ここで大事なのは、依頼を受けた側にとって、どういう状態になれば完了とみなせるか明確になっていれば、そのゴールに向けて支援しやすいということです。

そのためにも、完了の定義やどのような支援を求めているのか共通認識を持てるように起票しましょう。スクラム開発の完了の定義というと、イメージしやすいかもしれません。

ここにコストをかけることで、効率的に非同期に動くことができます。

4.緊急度を正しく設定

DevIO_2024_On_Effective_AWS_Support_04

4 つ目のプラクティスは「緊急度を適切に設定」です。

緊急度は優先度と言い換えても良いかもしれませんが、明確に定義されており、特に高い緊急度はビジネスへのインパクトを前提としています。そのためにも、高い緊急度を設定する際は、状況が緊急度の定義を満たしていると判断できる具体的な根拠も添えるようにしましょう。

アカウント系と技術系は、どちらも5段階の緊急度が定義されています。

DevIO_2024_On_Effective_AWS_Support_05

DevIO_2024_On_Effective_AWS_Support_06

技術系で2番目に緊急度が高い「本番環境のシステム停止中」の場合、「ビジネスが深刻な影響を受けている。アプリケーションの重要な機能が利用できない」と定義されています。ECサイトであれば、障害に伴う機会損失など、具体的な情報を提供すると緊急度の根拠としての説得力が増します。

既存のケースの緊急度が変化する場合もあります。

緊急度を上げる場合は、新規ケースを高い緊急度で起票し、既存のケースを参照しましょう。高緊急度だったケースにおいて、一時回避等で障害が解消された場合は、緊急度を下げましょう。

https://dev.classmethod.jp/articles/aws-support-case-severity-selection/

5.1ケース=1質問

DevIO_2024_On_Effective_AWS_Support_07

5つ目のプラクティスは「1ケース=1質問」です。

ひとつのケースに複数の質問が混ざっていると、回答を用意するまでに時間がかかったり、回答は1エンジニアが作成するため、複数サービスを対応するとなると難易度も上がります。また、すべての質問が解決されるまでケースをなかなか解決できないなど、様々な問題が伴います。

ケースを正しく分割することで、適材適所にそれぞれのスペシャリストが迅速に並列に対応して、早期解決することが期待できます。ただし、同じサービスの仕様確認のように、関連する質問は1ケースにまとめて問題ありません。発生中の障害に対して、障害復旧と原因調査の支援を受ける場合、この2つは対応内容も時間軸も異なります。

緊急性のある複数の質問に対しては、まずは障害復旧の支援だけを依頼し、その後原因調査を依頼するなど、質問間で優先度をつけて対応を依頼すると良いでしょう。

6.トラブルシュートは再現性が命

DevIO_2024_On_Effective_AWS_Support_08

6つ目のプラクティスは「トラブルシュートは再現性が命」です。

100%再現可能な状態まで原因を絞り込めていれば、解決したも同然です。トラブルシュートの多くの時間は問題を手元で再現することにさかれます。完全な再現手順までたどり着けていなくても、問題の切り分けができていれば、共有しましょう。

原因の絞り込みに大いに役に立ちます。

7.ログは重要な手がかり

DevIO_2024_On_Effective_AWS_Support_09

7つ目のプラクティスは「ログは重要な手がかり」です。

サービスを運用していると、AWSの操作ログ、ロードバランサーのアクセスログ、アプリケーションログなど様々なログが発生します。障害時期を特定したら、影響を受けた時間帯のログを提供しましょう。

ログはテキスト情報のため、利用しやすいようにテキスト形式で共有し、コンソールのエラーメッセージもスクリーンキャプチャのような画像形式で共有するのは控えましょう。また、共有時には機密情報はマスクしましょう。

8.時刻はタイムゾーンを明確に

DevIO_2024_On_Effective_AWS_Support_08_timezone

8つ目のプラクティスは「時刻はタイムゾーンを明確に」です。

AWSでは主にUTCと日本標準時のようなローカルタイムという2種類の時刻が用いられ、メトリクスやログはこのどちらかの基準時が利用されています。

時刻を含んだ情報を伝えるときには、UTC・JSTのようなタイムゾーンも添えるようにしましょう。

9.解決理由を添えてクローズ

DevIO_2024_On_Effective_AWS_Support_09_close

9つ目のプラクティスは「解決理由を添えてクローズ」です。

サポートの支援で解決した、自己解決した、AWS外の問題が原因だったなど、解決理由は様々です。

能動的に解決理由を添えてクローズすることで、起票者・対応者の双方にナレッジを蓄積できます。

時間の経過に任せた受動的な自動クローズにまかせないようにしましょう。類似の障害に陥って過去ログを漁った時に、結論があやふやなのは、双方にとって不幸です。

10.不満がなければ満点評価

DevIO_2024_On_Effective_AWS_Support_10

最後の10個目のプラクティスは「不満がなければ満点評価」です。

サポートを起票すると、回答内容やケースそのものについてフィードバックすることが可能です。この評価は5段階で、文字通りでは真ん中の3が「平均」です。

日本人は「3:平均」を基準に評価しがちですが、海外製サービスでは、不満がなければ星5つの「非常に良い」を付ける文化圏です。満点をベースラインとして、不満があれば減点するようにしてください。

また、このフィードバックには自由記入欄があります。この欄には、ポジティブなものネガティブなもの、どんなに些細なことであっても、対応時の具体的なエピソードを添えると、良い行動を継続したり、担当者のモチベーションを高めたり、不備のある行動を改善したりと、品質改善に繋げられます。

ぜひご記入ください。

まとめ

最後に本日紹介したAWSサポート活用のベストプラクティスを再掲します。

  1. 起票前にもう一度調べてみよう
  2. 2種類の窓口を使い分ける
  3. 解決の定義を明確に
  4. 緊急度を正しく設定
  5. 1ケース=1質問
  6. トラブルシュートは再現性が命
  7. ログは重要な手がかり
  8. 時刻はタイムゾーンを明確に
  9. 解決理由を添えてクローズ
  10. 不満がなければ満点評価

AWSサポートが支援しやすいように、課題をうまく切り出して定義し、AWSの専門家であるAWSサポートをうまく活用しましょう。

DevIO_2024_On_Effective_AWS_Support_10_tips

参考

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.